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Abstract 



The data telegrams are transmitted between two stations over a transmission path by a transceiver 
for simultaneous operation in both directions. After a transmission interference, synchronisation 
telegrams are used for correct sequential resuming of the data telegram exchange. 
Packs are formed for the transmission, contg. one or several telegrams, i.e. data, synchronisation 
telegrams or a sequence of such telegrams, if necessary, synchronisation telegrams are inserted 
into a pack whose transmission has not been terminated. The pack is pref. formed, using a 
sequential characteristic set in the telegrams with the exception of the last one. 
ADVANTAGE - Improved transmission with reduced faults. 
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(§) Verfahren zur Ubertragung von Datentelegrammen 

Das Verfahren kann angewendet warden zur Ubertragung 
von Datentelegrammen zwischen zwei Stationen, z. B. rwei 
Rechnern einer letttechnischen Einrichtung. Zur Steuerung 
des Ablaufs, und zwar zur folgerichtigen Ubertragung von 
Datentelegrammen im FuM-Duptex-Betrieb, auch bei Uber- 
tragungsstorungen, werden definierte Synchrontsationste- 
legramme benutzt. Mehrere Datentelegramme werden als 
Paket Obertragen, wobei erforderliche Synchronisattonste- 
legramme in ein gerade gesendetes Paket von Datentele- 
grammen eingeschleust und in die Telegrammfolge einge- 
bettet werden. 
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Die Erfindung bezieht sich auf ein Verfahren zur 
Obertragung von Datentelegrammen zwischen zwei 
Statlonen uber eine Obertragungsstrecke. die fur ein 5 
gleichzeitiges Senden und Empfangen in beiden Rich- 
tungen eingerichtet ist, und wobei nach einer Obertra- 
gungsstdrung eine folgerichtige Fortsetzung der Daten- 
Qbertragung, anknupfend an das zuletzt richtig ubertra- 
gene Datentelegramm. erfolgt 10 

Ein solches Verfahren ist aus der DE-PS 34 15 936 
bekannt Bei diesenn Verfahren wird eine folgerichtige 
Wiederaufnahme eines Austausches von Datentele- 
grammen dadurch bewirkt daB die Station, die ein ver- 
falschtes Datenteiegramm empfangt, ein prufbares Syn- 15 
chronisationstelegramm sendet, wobei die Synchronisa- 
tionstelegramme einen Zahiwert enthalten, der die An- 
zahl der von der jeweiligen Station seit der letzten Sen- 
dung eines Datentelegramms nacheinander gesendeten 
Synchronisationsteiegramme angibt Die Datentele- 20 
gramme enthalten dagegen keine Zahlwerte oder son- 
stige Kennung. Dadurch wird im fehlerfreien Fall eine 
effiziente Datenubertragung erreicht Trotzdem besteht 
besonders fiir eine Anwendung in leittechnischen Anla- 
gen mit hohem Datenaufkommen Bedarf an einer wei- 25 
teren Steigerung der Obertragungsleistung und an einer 
Erganzung des Ubertragungsprotokolls. 

Der Erfindung liegt daher die Aufgabe zugrunde. ein 
verbessertes Verfahren zur Obertragung von Datente- 
legrammen anzugeben. 30 

Diese Aufgabe wird gelost durch ein Verfahren zur 
Obertragung von Datentelegrammen in einer Obertra- 
gungseinrichtung zwischen zwei Stationen iiber eine 
Obertragungsstrecke. die fur ein gleichzeitiges Senden 
und Empfangen in beiden Richtungen eingerichtet ist, 35 
welches nach einer Obertragungsstorung mit Hilfe von 
Synchronisationstelegrammen eine folgerichtige Wie- 
deraufnahme des Austauschs von Datentelegrammen 
sicherstellt, wobei fflr die Obertragung Pakete gebildet 
werden, die aus einem oder mehreren Telegrammen 40 
bestehen, bei denen es sich um Datentelegramme, Syn- 
chronisationsteiegramme oder um eine Folge von Da- 
ten- und Synchronisationstelegrammen handeln kann, 
und wobei in ein Paket. dessen Sendung noch nicht ab- 
geschlossen ist, Synchronisationsteiegramme im Be- 45 
darfsfall eingefugt werden. 

Die mit der Erfindung vorgeschlagene Paketierung 
von Datentelegrammen und die Moglichkeit, Synchro- 
nisationsteiegramme als Steuerungstelegramme in eine 
laufende Obertragung eines Pakets von Telegrammen 50 
einzufugen, fuhrt zu einer Steigerung der Obertra- 
gungsleistung. Da eine Obertragung von Paketen in bei- 
den Obertragungsrichtungen gleichzeitig ablaufen kann 
und in die Folge von Datentelegrammen eingeschleuste 
Synchronisationsteiegramme empfangsseitig abge- 55 
zweigt und unverzuglich ausgewertet werden, kann die 
Obertragungseinrichtung schnell auf Obertragungsstd- 
rungen reagieren und eine wiederholte Sendung veran- 
lassen. 

Nach einer vorteilhaften Ausgestaltung erfolgt die eo 
Paketbildung dadurch, daB die einzelnen Telegramme 
eine Folgekennung enthalten, die besagt, daB minde- 
stens ein weiteres Telegramm folgt Wenn diese Folge- 
kennung nicht gesetzt ist, handelt es sich um das letzte 
Telegramm eines Pakets. Telegramme sind eine Folge 65 
von Zeichen. 

Weiterhin wird vorgeschlagen, die beiden Stationen 
der Obertragungseinrichtung im Normalbetrieb gleich- 



berechtigt arbeiten zulfSen. jedoch zur Initialisierung 
und zur Prufung der Funktionsfahigkeit auf einen ma- 
ster/slave-Betrieb umzustellen. 

Im master-sIave-Betrieb wird die slave-Station aufge- 
forderi, ein definiertes Synchronisationstelegramm als 
Antworttelegramm zu senden. Das Eintreffen des Ani- 
worttelegramms kann zeitlich uberwacht und fur eine 
Fehlerauswertung genutzt werden. 

Zur Steuerung des Obertragungsablaufs. insbesonde- 
re bei gestort empfangenen Telegrammen. werden un- 
terschiedliche Synchronisationsteiegramme verwendet 
und als Kontext einer Station bezeichnete Merker und 
Zahler benutzt Empfangene Telegramme werden nur 
dann zur weiteren Verarbeitung freigegeben, wenn das 
gesamte Paket storungsfrei empfangen wurde. 

Das Obertragungsverfahren ist in Form von Regeln 
definiert, die in drei Gruppen gegliedert sind. Weitere 
Einzelheiten und Vorteile des Verfahrens sind aus dem 
in der Zeichnung dargestellten und nachstehend be- 
schriebenen Ausfuhrungsbeispiel ersichtlich. 
Es zeigen: 

Fig. 1 ein Blockdiagramm. das die Struktur zweier 
Stationen angibt, die geeignet sind zur Durchfuhrung 
des erfindungsgemaBen Obertragungsverfahrens. Au- 
Berdem sind die Namen der verwendeten Telegramme 
angegeben. 

Fig. 2 liefert eine Legende zum Blockdiagramm nach 
Fig. I sowie zu einem Obertragungsdiagramm nach 
Fig. 3.1 bis 3.4. 

Fig. 3.1 bis 3.4 Darstellung von vier Teilen eines bei- 
spielhaften Obertragungsdiagramms. 



1.0 Ausfuhrungsbeispiel 

Das Ausfuhrungsbeispiel bezieht sich auf ein Ober- 
tragungsverfahren. das im sogenannten full-duplex-Be- 
trieb arbeitet und fur den Einsatz in der Gebaudeleit- 
technik entwickelt wurde. 

2.0 Eigenschaften des Verfahrens 

Das Verfahren eignet sich zur Obertragung digitaler 
Daten zwischen zwei Prozessoren oder Rechnem. die 
hier als Stationen bezeichnet sind. Das Verfahren defi- 
niert die Arbeitsweise der Obertragungseinrichtung in 
jeder Station. 

Das Verfahren ermoglicht die optimierte, gesicherte 
und gleichzeitige Obertragung von Daten zwischen 
zwei Stationen. Diese Daten werden hier als Datentele- 
gramme bezeichnet Die kontrollierte Obertragung die- 
ser Datentelegramme wird ermoglicht durch zusatzli- 
che Obertragung von Steuerinformation, hier als Syn- 
chronisationsteiegramme bezeichnet. 

Das zeitliche Auftreten von zu sendenden Datentele- 
grammen. also das Datenaufkommen, kann dabei konti- 
nuierlich oder auch spontan erfolgen. 

Das Verfahren ermoglicht die Obertragung uber ein- 
fache asjTichrone und serielle Schnittstellen und beno- 
tigt als Obertragungsmedium nur eine einfache Dreia- 
derleitung. 

Eine optimierte Obertragung wird erzielt durch Pa- 
ketierung der zu ubertragenden Telegramme, 

Eine gesicherte Obertragung wird erzielt durch die 
Obertragung eines Paritatsbits in jedem Zeichen eines 
Telegramms und einer Prufsumme innerhaib jedes Ein- 
zeltelegramms. Gesendete Telegramme werden in ei- 
nem backup-Speicher gehalten, bis sie durch die Part- 
nerstation quittiert werden. Dadurch wird eine Wieder- 
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holung des Sendens eines kompletten Pal^K oder ei- 
nes Teils des Paketes ermoglicht nach fehlerhaftem 
Empfang in der Partnerstation. 

Das Verfahren ermoglicht gleichzeitiges Senden von 
Datentelegrammen und Synchronisationstelegrammen 
aus jeder Station, so daB die Obertragung "full-duplex" 
erfolgen kann. Dies bedeutet, daB beide Stationen prin- 
zipieil immer bereit sind, Telegramme zu empfangen. 

Das gleichzeitige Obertragen von Telegrammen zwi- 
schen beiden Stationen verhindert, daB das Senden von 
Telegrammen wegen des Empfangs von Telegrammen 
und der Empfang von Telegrammen wegen des Sendens 
von Telegrammen verzogert wird. 

Das Senden von Daten ist nur dann moglich, wenn der 
empfangende Prozessor seine Bereitschaft, ab jetzt wie- 
der Daten zu empfangen, dem sendenden Prozessor si- 
gnalisiert hat, was als kontrollierte Weitergabe von Da- 
ten bezeichnet wird. 

Innerhalb der Initiierung der Obertragung ist einer 
Station eine master-Funktion zugeteilt, nach Ende der 
Initialisierung arbeiten beide Stationen symmetrisch. In 
Zeitphasen, in denen keine Datentelegramme zur Ober- 
tragung vorliegen, kontroUiert die master-Station die 
Funktionsfahigkeit der slave-Station und des Obertra- 
gungsweges durch zyklisches Senden eines zu beant- 
wortenden Synchronisationstelegramms. Dieser Ver- 
f ahrensschritt wird mit lifeloop bezeichnet 

3.0 Einsatzmoglichkeiten des Verfahrens 

Die Eigenschaf ten des Verfahrens, wie optimierte, ge- 
sicherte und gleichzeitige Datenubertragung sowie gun- 
stiges Verhaltnis zwischen ubertragenen Nutz- und 
Steuertelegrammen und die Moglichkeit, Daten spon- 
tan senden zu konnen. bieten dessen Einsatz in der Pro- 
zessleittechnik an. 

Nach dem Verfahren konnen prinzipiell jeweils zwei 
Rechner gekoppelt werden. Es unterstutzt jedoch auch 
vermaschte Rechnernetze, bestehend aus Kaskadierun- 
gen Oder stemfdrmigen Strukturen. Bei Kaskadierung, 
also Hintereinanderschaltung von Rechnem, ist in je- 
dem Rechner, der innerhalb des Gesamtubertragungs- 
weges zwischen zwei anderen Rechnern angeordnet ist, 
die Obertragungseinrichtung doppelt vorhanden. Bei 
sternformigen Strukturen ist in jedem Mittelpunkts- 
Rechner die Obertragungseinrichtung in der gleichen 
Anzahl vorhanden, wie die Anzahl von Satelliten-Rech- 
nern. die an den Mittelpunkts-Rechner angeschlossen 
sind. 

4.0 Definition des Ubertragungsprotokolls 
4,1 Struktur einer Station 

Fig. 1 zeigt die Struktur einer ersten Station U und 
einer zweiten Station 1, die identisch sind Fig. 2 zeigt 
weitere Einzelheiten zum Kontext der Station. 

Jede Station U. I besteht aus einem ersten Puffer 1 fiir 
zu sendende Datentelegramme und einem zweiten Puf- 
fer 2 fur zu empfangende Datentelegramme. Diese bei- 
den Puffer 1, 2 dienen innerhalb einer Station U, I zur 
Weitergabe von Datentelegrammen zwischen der 
Obertragungseinrichtung und den datenverarbeitenden 
Funktionen der Station U. L 

Der Datenempfangspuffer 2 der Stationen muB min- 
destens so groB definiert werden, wie der Datensende- 
puffer 1 der Stationen U, L Diese GroBe bestimmt auch 
die GroBe eines nicht dargesiellten backup-Speichers 



und die maximale Anzahl einem Paket enthalie- 

nen Datentelegramme. 

Die Station U hat die im Abschnitt 2.0 bereits erwahn- 
te Funktion einer master-Statioa durch welche die In- 
5 itialisierung der Obertragung und die Uberwachung li- 
feloop ausgelost wird. 

Innerhalb der aus den Stationen U, I bestehenden 
Obertragungseinrichtung ist das hier beschriebene Ver- 
fahren implementiert. Die Aufgabe der Obertragungs- 
10 einrichtung ist die Anwendung der Daten-, Protokoll- 
und backup-Regeln bezuglich: 

— Empfang von Telegrammen; Prufung auf Validi- 
tat (Priif summe, Paritat). 

— Trennung von empfangenen Daten und Syn- 
chronisationstelegrammen. 

Datentelegramme werden in den Datenempfangs- 
puffer eingetragen, Synchronisationstelegramme 
bewirken das Senden von Daten und Synchronisat- 
instelegrammen und die Aktualisierung des Sta- 
tionskontextes (vergL Abschnitt 43). 

— Aktualisierung des Stationkontextes, 
Als IContext werden stationstypische Merker und 
Zahler bezeichnet. - 

— Senden von Telegrammen. - 
Anhand des Sutionskontextes werden vorliegende 
Datentelegramme aus dem Datensendepuffer und 
Synchronisationstelegramme gesendeL 



15 



20 



25 



30 



4.2 Telegrammarten 



Zwischen den Stationen werden Daten- und Synchro- 
nisationstelegramme ausgetauscht- Sie werden durch ih- 
re Namen gekennzeichneL Der erste Buchstabe des Na- 
35 mens bezeichnet die absendende Station, also U oder L 
Jedes Telegramm enthalt innerhalb der Obertragung 
eine Folgekennung. die angibt. ob ein weiteres Tele- 
gramm innerhalb dieses Paketes folgt oder ob dieses 
Telegramm, das letzte innerhalb des Paketes ist Die 
40 Folgekennung wird in der Obertragungseinrichtung 
dem zu sendenden Telegramm in entsprechender Pola- 
ritat hinzugefugt und aus dem empfangenen Telegramm 
nach Prufung seiner Polaritat entfernt. 

Datentelegramme werden als xD bezeichnet 
45 Folgende Synchronisationstelegramme werden ver- 
wendet: 

- xREN (UREN, IREN), request next 
Anforderung des Sendens weiterer Datentele- 

50 gramme. 

- xREL(UREL, IREL), request last 
Anforderung des wiederholten Sendens der zuletzt 
gesendeten Telegramme. 

Dieses Telegramm enthalt die Kennungen VAREC 
55 und CIVTEL (vergL Kontext der Station. Abschn. 
43). 

- xxLIF(URLIF. lALIF), request/answer life. 
Station U fordert mittels URLIF ein Lebenssignal 
von Station I an, das diese mit I AUF der Station U 

60 sendet (vergL lifeloop, Abschn. 4.6). 

- xRINI (URINI, IRINI), request initialisation, 
Mit URINI fordert Station U eine Initialisierung 
der Station 1 an. 

Mit IRINl fordert Station I ein Telegramm URINI 
65 von Station U an. 

Nach Empfang von xRlNI initiieri jede Station ih- 
ren Kontext 

- xACK(UACK,IACK) acknowledge- 
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Quittierung eines valide und komplett empfange- 
nen Pakeis. Dieses Telegramm enthalt die Ken- 
nung VAREC (vergl. Kontext der Station, Abschn. 
4.3). 

43 Kontext der Station 

AIs Kontext einer Station warden stationstypische 
Merker und Zahler bezeichnet 
Der Kontext besteht aus: 

— backup 

Zur Telegrammwiederholung nach Empfang eines 
Telegramms xREL muC ein backup fur gesendete 
Telegramme gefuhrt werden. 
Der backup-Speicher ist als umlaufender Puffer 
(Ringpuffer) gestaltet 

Der backup-Speicher muB mindestens dreimal so 
groB dimensioniert werden, wie die maximale An- 
zahl von einzelnen Datentelegrammen innerhalb 
eines Pakets. 

(Vergl. Paket, Abschn. 4.4) 

Das backup kann zu keinem Zeitpunkt mehr Da- 
tentelegramme enthalten. als maximal in einem Pa- 
ket enthalten sind. 

(VergL backup- Regeln, Abschn. 4.73) 

— VAREC (valid received) 

VAREC ist ein Zahler fur die Anzahl der valide 
(unverfalscht) empfangenen Telegramme seit Sen- 
den des letzten Telegranms xACK. 
Bei Senden von xREL oder xACK wird der aktuelle 
Kontext VAREC diesen Telegrammen eingeschrie- 
ben. Bei Empfang von xREL oder xACK wird der 
darin enthaltene VAREC fur die Referenzierung 
des backup benotigt 
(Vergl. Protokoll-Regeln. Abschn, 4 J J) 

— CIVSTA (counter invalid receiving in station) 
CIVSTA ist ein Zahler fur die Anzahl der invalide 
(verf alscht) empfangenen Telegramme. 
Bei Senden von xREL wird der aktuelle Kontext 
CIVSTA diesem Telegramm als CIVTEL (counter 
invalid receiving in telegramm) eingeschrieben. 
Bei Empfang von xREL wird der darin enthaltene 
Kontext CIVTEL mit dem aktuellen CIVSTA ver- 
glichen, um zu entscheiden. ob Telegramme aus 
dem backup wiederholt zu senden sind oder ob 
xREL zu senden ist. um die Partnerstation zum wie- 
derholten Senden aus derem backup aufzufordern. 
Diese Funktionalitat ermoglicht, daB nach mehr- 
fach invalide (verfalscht) empfangenen xREL (ian- 
ger andauernde Obertragungsstorung, d. h. nur Te- 
legramme URELyiREL werden noch gesendet) ge- 
nau die Station das Senden aus ihrem backup be- 
ginnt, deren Telegramme zuerst von der Partner- 
station verfalscht empfangen wurden. 
(Vergl. Protokoll-Regeln, Abschn. 4.7.2) 

— WRR(wait until complete repetiton received) 
WRR ist ein Merker der angibt, ob nach Senden 
eines Telegramms xREL der Empfang aller Tele- 
gramme abgeschlossen ist, deren wiederholtes Sen- 
den angefordert wurde (WRR = 0. "geloscht"), oder 
ob deren Empfang noch nicht komplett abgeschlos- 
sen ist(WRR=l,"geset2t"). 
(Vergl. Protokoll-Regeln, Abschn. 4.7.2) 

4.4 Paket 

Ein Paket besteht aus einem oder mehreren Tele- 
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grammen, und zwar DaTen- oder Synchronisationstele- 
grammen. wobei im letzien Telegramm eines Pakets die 
Folgekennung nicht gesetzt. aber in alien anderen Tele- 
grammen gesetzt ist Ein Paket kann somit auch nur aus 
5 Synchronisationstelegrammen bestehen. 

Nach dem Empfang eines Telegramms xREN werden 
alle Datentelegramme gesendet, die zu diesem Zeit- 
punkt im Datensendepuffer vorliegen. 

Dadurch kann bei Vorliegen von vielen zu ubertra- 
10 genden Datentelegrammen das Verhaltnis aus der An- 
zahl von Datentelegrammen und von Synchronisation- 
stelegrammen wesentlich optimiert werden. 

In dieses Paket werden gegebenenfalls Synchronisa- 
tionstelegramme eingebettet, falls diese zu diesem Zeit- 
15 punkt zu senden sind. Liegt nur ein Datentelegramm im 
Datensendepuffer vor, wird dieses sofort gesendet, ohne 
auf weitere Datentelegramme zu warten. Die maximal 
mogliche Anzahl von Telegrammen in einem Paket er- 
gibt sich aus der maximal moglichen Anzahl von Daten- 
20 telegrammen im Datensendepuffer zuzuglich der im Pa- 
ket eingebetteten Synchronisationstelegramme. 

Die maximale Anzahl der in ein Paket eingebetteten 
Synchronisationstelegramme kann nicht genau festge- 
legt werden, was durch die Dyitamik der fullduplex- 
25 Obertragung bedingt ist Wird z. B. gerade das Senden 
von 64 Datentelegrammen in Station U begonnen, und 
die Station U hat gerade ein Paket mit genau einem 
Datentelegramm empfangen und gespeichert, bettet die 
Station U sofort ein Synchronisationstelegramm UREN 
30 in das Paket an Station I ein. welches Station I veranlaBt, 
sofort ein weiteres Paket mit genau einem Datentele- 
gramm zu senden, da in Station I zu diesem Zeitpunkt 
nicht mehr Datentelegramme vorliegen. Dieses wird in 
Station U empfangen und gespeichert und sofort eiii 
35 neues Synchronisationstelegramm UREN in die immer 
noch laufende Obertragung von Station U zu Station I 
eingebettet. Somit treten innerhalb eines Pakets schon 
zwei UREN auf. 

Die ebenfalls beteiligten Telegramme xACK sind in 
40 diesem vereinfachten Beispiel nicht berucksichtigt 

Die Begrenzung der Anzahl von Datentelegrammen 
innerhalb eines Pakets ermoglicht die Dimensionierung 
der Datenempfangs- und Datensendepuffer. welche ge- 
nerell nur Datentelegramme (keine Synchronisationste- 
45 legramme) enthalten. Synchronisationstelegramme 
werden vom Empfanger nicht gespeichert. sondern es 
wird innerhalb der Obertragungseinrichtung sofort auf 
diese reagiert 

50 43 Initiierung der Obertragung 

Eihe Initiierung der Obertragung ist notig nach dem 
Start (Einschalten, Erstanlauf) oder Neustart (vergl. 
Fehlerbehandlung bei gestorter Obertragung im Ab- 
55 schnitt 4,8) einer der beiden Stationen. 

Wahrend der Initialisierung arbeiten die Obertra- 
gungseinrichtungen der Stationen nicht symmetrisch. 
sondern es erfolgt eine master/slave-RoUenverteilung, 
wobei hier die Station U als master definiert ist. 
60 Wird der master gestartet, initiiert er seinen Kontext 
(vergl. Protokoll-Regeln, Abschn. 4J2) und sendet das 
Synchronisationstelegramm URINI. Der slave emp- 
fangt dieses Telegramm und initiiert seinerseits seinen 
Kontext Nach AbschluB seiner Initialisierung sendet 
65 der slave das Synchronisationstelegramm IREN, er 
kann also Datentelegramme empfangen. Empfangt der 
master dieses Telegramm IREN, so sendet er seinerseits 
ein Telegramm UREN, was bedeutet, daB auch er Da- 
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tentelegramme empfangen kann. 

Wird der slave (Station I) gestartet, so fordert dieser 
seine Initialisierung durch den master an. Dazu sendet 
er das Synchronisationstelegramm IRINI. Nach dem 
Empfang eines Telegramms IRINI im master initiiert 5 
dieser seinen Kontext und sendet das Synchronisation- 
stelegramm URINI an den slave. 

Danach erfoigt der gleiche Ablauf wie beim Start des 
masters. 

Der Empfang des Telegramms URINI im slave lost 10 
bei dlesem eine Initiierung seines Kontextes aus. Da- 
nach sendet der slave ein Teiegramm IREN. Nach Emp- 
fang dieses Telegramms IREN im master sendet dieser 
das Synchronisationstelegramm UREN. Beide Statio- 
nen konnen nun Datentelegramme empfangen. 15 

Zusatzlich zur Initiierung des Kontextes kann. falls 
notig. auch eine Initiierung innerhalb der datenverarbei- 
tenden Funktionen der Station stattfinden. 

Im master wird der Zeitraum zwischen Senden von 
URINI und Empfang von IREN uberwacht (timeout). 20 
Kann der master das Synchronisationstelegramm IREN 
nicht rechtzeitig oder nicht valide (unverfalscht) emp- 
fangen. liegt eine gestorte Obertragung vor (vergl. Feh- 
lerbehandlung bei gestorter Obertragung, Abschn. 4.8 
und Neustart der Obertragung. Abschn. 4.83). 25 

4,6 Lifeloop 

In langeren Zeitphasen, in denen in keiner Station 
Datentelegramme zur Obertragung vorliegen, ist es 30 
sinnvoll, die Funktionsfahigkeit des (Jbertragungsweges 
zu kontrollieren. Diese KontroUe.wird mittels einer life- 
loop durchgefiihrt 

Die lifeloop ist nicht symmetrisch implementiert. d. h. 
nur eine Station, als master bezeichnet, startet aktiv die 35 
life-loop, nachdem sie nach defmierter Zeit kein Teie- 
gramm empfangen hat Mittels der lifeloop wird auch 
die Funktionalitat des slave kontrolliert Hier ist Station 
U als master definiert 

Der master sendet das Synchronisationstelegramm 40 
URLIF, und erwartet innerhalb einer bestimmten Zeit 
das vom slave als Antwort zu sendende Synchronisa- 
tionstelegramm lALIF. 

Kann der master lALIF nicht rechtzeitig empfangen, 
liegt eine gestorte Obertragung vor (vergl. Fehlerbe- 45 
handlung bei gestorter Obertragung, Abschn. 4.8). 

4.7 Obertragungs-Regeln 

Das vorliegende Obertragungsverfahren ist definiert 50 
als Summe einzelner Regeln, die in der Obertragungs- 
einrichtung implementiert sind. 

Diese Regeln gelten gleichermaQen sowohl fur die 
Station U wie fur die Station L 

Die Regeln sind in drei Gruppen zusammengefaBt: 55 

— Daten-Regein :(DR n) Ubergabe von Datente- 
legrammen 

— ProtokoU-Regeln :(PR n) Abfolge von Tele- 
grammen, Kontext 60 

— backup-Regeln :(BR n) Referenzierung des bak- 
kup 

Bei den in den Regeln verwendeten Begriffen "xACK 
(varec)" und "xREL (varec) (civtel)" bedeutet (varec) den 65 
im Teiegramm enthaltenen Wert des Zahlers VAREC, 
(civtel) den im Teiegramm enthaltenen Wert des Zah- 
lers CIVSTA jeweils als Kopie aus dem Kontext der 
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sendenden Station U oder 1. 



4.7.1 Daten-Regeln 

- Datenregel DR 1 

Datentelegramme werden, sobald sie in einem Da- 
tensendepuffer vorliegen, erst dann gesendet, nach- 
dem zuvor ein Synchronisationstelegramm xREN 
empfangen wurde. Alle Telegramme aus dem Da- 
tensendepuffer werden innerhalb eines Pakets ge- 
sendet 

- Datenregel DR 2 

Ein Synchronisationstelegramm xREN wird nach 
dem Empfang von Datentelegrammen in einem 
Datenempfangspuffer erst dann gesendet, wenn 
diese von den datenverarbeitenden Einrichtungen 
ausgelesen wurden, und somit der Datenempfangs- 
puffer wieder frei ist fur neu zu empfangende Da- 
tentelegramme. 

- Datenregel DR 3 

Bei storungsfreier Obertragung werden Datentele- 
gramme xD und Synchronisationstelegramme 
xREN, xACK, URLIF, lALIF ausgetauscht. 

4.7.2 ProtokoU-Regeln i 

- Protokoll-Regel PR 1 

Datentelegramme und Synchronisationstelegram- 
me konnen innerhalb eines Pakets gemischt auftre- 
ten. 

- Protokoll-Regel PR 2 

Das Synchronisationstelegramm xACK dient nur 
zur Steuerung fQr das Loschen des backup-Spei- 
chers, nicht aber zur Synchronisation von Senden/ 
Empfangen. Somit muB nach dem Senden eines Pa- 
kets vor dem Senden eines nachsten Pakets nicht 
auf den Empfang eines xACK gewartet werden. 

- Protokoll-Regel PR 3 

Iniuierung des stationseigenen Kontexts nach ei- 
. nem Start der Station: 
CIVSTA = 0 counter invalid receiving in station 
VAREC = 0 counter for valid tel received (tel = Te- 
iegramm) 

backup = 0 backup fur gesendete tel ist leer 
Merker WRR = 0 Wait until complete repetition 
received 

- Protokoll-Regel PR 4 

Ein originates (nicht wiederholtes) Teiegramm 
xACK (varec) wird sofort gesendet nach Empfang 
eines validen und kompletten Pakets, das andere 
Telegramme als xACK, bzw. xREL enthalt. 
Nach Senden eines originalen Telegramms xACK 
(varec) wird VAREC geloschL 
Nach Senden eines Telegramms xACK (varec) aus 
dem backup wird VAREC nicht geloschL 

- Protokoll-Regel PR 5 

Jedes original gesendete Teiegramm, auBer xREU 
wird in das backup geschrieben. 
Bei einem original gesendeten Teiegramm xACK 
(varec) wird somit auch dieser (varec), also dieser 
Wert des Zahlers VAREC, Bestandteil des Tele- 
gramms im backup. 

- Protokoll-Regel PR 6 

Jedes valide empfangene Teiegramm, auBer xREL, 
wird in VAREC gezahlt. 

(Fur ein empfangenes xREL gelten spezielle Re- 
geln). 

- Protokoll-Regel PR 7 



E 39 25 843 Al 



0 



Nach jedem valide empfangenen Telegramm, au- 
Ber xREU wird CIVSTA geloscht. 
(Fur ein empfangenes xREL gelten spezielle Re- 
gein). 

- Protokoll-Regel PR 8 5 
Nach Empfang eines Telegramms xACK (varec) 
werden sofort, ohne auf das Ende des Pakets zu 
warten, (varec)-Telegramme aus dem backup ge- 
loscht, 

- Protokoll-Regel PR 9 lO 
Falls mehrere Typen von Telegrammen "gleichzei- 
tig" zu senden sind. gilt folgende Reihenfolge: 

1) Telegramnne aus backup (reihenfolgerichtig) 

2) original xACK 

3) original xREN is 

4) original xREL 

5) original xxLIF 

6) original xRINI 

7) original Datentelegramme 

- Protokoll-Regel PR 1 0 20 
Nach Empfang eines Telegramms xREL (varec) 
(civtel) wird wie folgt gepruft/reagiert ohne auf das 
Ende des Pakets zu warten: 

- Protokoll-Regel 10.1 

CIVSTA - CIVTEL (vgl. Abschn. 43) 25 
Falls CIVSTA nicht 0 ist, wird CIVSTA inkre- 
mentiert. 

Unabhangig von CIVSTA gilt: 

Keine Telegramme werden im backup ge- 

loscht. Alle Telegramme im backup, aber nicht 30 

die altesten (ersten) n Telegramme im backup 

(n = (varec) aus empfangenem Telegramm 

xREL). werden als Wiederholung gesendet 

(vergl. Bemerkung zu PR IOjc, weiter unten). 

Ein aus dem backup gesendetes Telegramm 35 

xACK loscht VAREC nicht 

Ein aus dem backup gesendetes xACK enthait 

das dazugehorige (varec) aus backup. 

Falls CIVSTA nicht 0 ist, wird xREL (varec) 

(civtel) gesendet 40 

Kurzformulierung 

CIVSTA ist nicht 0: - CIVSTA wird inkre- 
mentiert 45 

— Telegramm-Wiederholung falls moglich 

— xREL senden 

CIVSTA ist 0: - Telegramm-Wiederholung 
falls moglich. 

- Protokoll-Regel PR 10:2 , 50 
CIVSTA ist groQer als CIVTEL: 

CIVSTA wird nicht inkrementiert 
Keine Telegramme werden im backup ge- 
loscht Alle Telegramme im backup, aber nicht 
die ersten n Telegramme im backup (n=(va- 55 
rec) aus empfangenem Telegramm xREL), 
werden als Wiederholung gesendet (vergl. Be- 
merkung zu PR IQjc, weiter unten). 
Ein aus dem backup gesendetes xACK loscht 
VAREC nicht 60 
Ein aus dem backup gesendetes xACK enthalt 
das dazugehorige (varec) aus backup. 
xREL (varec) (civtel) wird gesendet 



Kunzformulierung 

Telegramm-Wiederholung fails moglich, 
xREL senden. 



65 



— Protokoll-Regel PR 10.3 
CIVSTA ist kleiner als CIVTEL: 
CIVSTA wird geloscht 

Keine Telegramme werden im backup ge- 
loscht Alle Telegramme im backup, aber nicht 
die ersten n Telegramme im backup (n = (va- 
rec) aus empfangenem Telegramm xREL), 
werden als Wiederholung gesendet (vergl. Be- 
merkung zu PR IOjc, weiter unten). 
Ein aus dem backup gesendetes xACK loscht 
VAREC nicht 

Ein aus dem backup gesendetes xACK enthalt 
das dazugehorige (varec) aus backup. 
Falls Marker WRR gesetzt ist (=1), wird 
xREL (varec) (civtel) gesendet 

Kurzformulierung : 

Merker WRR ist 1 : - CIVSTA wird geloscht 

— Telegramm-Wiederholung, 
falls moglich 

— xREL senden 

Merker WRR ist 0: - CIVSTA wird geloscht 

— Telegramm-Wiederholung falls moglich 

— Bemerkung zu PR 10^ 

Falls (varec) aus Telegramm xREL und die An- 
zahi der Telegramme im backup identisch sind, 
werden keine Telegramme aus dem backup 
gesendet, da dies nicht moglich/notig ist Diese 
Situation ist kein Fehler, sondem legal. 
Das wiederholte Senden aus dem backup fur 
"CIVSTA -CIVTEL" und "CIVSTA ist groBer 
als CIVTEL" (wenn (varec) aus Telegramni 
xREL kleiner ist als die Anzahl der Telegram- 
me im backup) und der Merker WRR ist notig 
zur Behebung folgender Problem-Situation, 
die wegen der fullduplex-Eigenschaften der 
Kopplung auftreten kann. 
Beide Stationen konnen zur gleichen Zeit feh- 
lerhafte Telegramme empf angen und somit ihr 
delay (vgl. Protokoll-Regel PR 13) gleichzeitig 
starten, aber beide delays konnen in ihrer Lan- 
ge "etwas" voneinander abweichen, weil in je- 
der Station jeweils auf den nachsten Impuls 
der internen Zeitbasis, (clock-tick) gewartet 
werden muC. 

Dies ist besonders fur hohe Baudaten kritisch, 
da dabei die delay-Differenz groBer sein kann 
als die Laufzeit eines Telegramms. Dabei kann 
die Station mit langerem delay xREL nicht 
empfangen, die Station mit kurzerem delay 
kann xREL empfangen. 

- Protokoll-Regel PR 1 1 

Merker WRR wird gesetzt nach jedem Senden von 
xREL (varec) (civtel), 

- Protokoll-Regel PR 12 

Merker WRR wird geloscht nach jedem Empfang 
eines kompletten Pakets. 

Falls xREL als letztes Telegramm eines Pakets 
empfangen wird, erfolgt das Loschen von Merker 
WRR erst nach Durchfuhrung des Vergleiches 
"CIVSTA ist kleiner. gleich oder groBer als CIV- 
TEL" und der dabei definierten Aktion (vergl. PR 
lOjc). 

- Protokoll-Regel PR 13 

Nach Empfang einer Storung, fiir deren Typ eine 
Telegrammwiederholung erlaubt ist(durch interfa- 
ce-Fehler, Prufsummen-Fehier verfalschies Tele- 
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gramm, etc., vergl. Fehlerbehandlun^WT gestorter 
Obertragung. Abschn. 4.8), wird CIVSTA inkre- 
mentiert, der Empfanger deaktiviert und ein delay 
(timer) gestartet. 

Wahrend des delay wind der Rest des verfalscht 5 
empfangenen Telegramms, bzw. Pakets ubertragen 
aber nicht empfangen. Die Dimensionierung des 
delay ist abhangig von der Zeit, die benotigt wird, 
um den Rest des Pakets zu ubertragen, also abhan- 
gig von der gewahlten Obertragungsgeschwindig- 10 

. keit (Baud- Rate) und der Lange des restiichen Pa- 
kets. Eine zu groBe Dimensionierung des delay ist 
unkritisch, reduziert aber die Reaktionszeit bei ge- 

,st6rter Obertragung, 

Wahrend des delay konnen weiterhin Telegramme 15 
gesendet werden. 

Nach Ablauf des delay wird xREL (varec) (civtel) 
gesendet und danach der Empfanger wieder akti- 
viert 

- Pro tokoll- Kegel PR 14 20 
Folgende Regeln gelten wenn zu einem Zeitpunkt 
kein Telegramm gesendet oder empfangen wird: 
VAREC in U = Anzahl der Telegramme im backup 
von I 

VAREC in I = Anzahl der Telegramme im backup 25 
von U. 

- Protokoli-Regel PR 15 

Wird in einem Paket ein xREN empfangen, konnen 
wieder Datentelegramme aus dem Datensendepuf- 
fer, falls vorhanden, gesendet werden. ohne auf das 30 
Ende des Empfangs des kompletten Pakets zu war- 
ten. (Vergl. Daten- Regeln, Abschn. 4.7.1) 

- Protokoll-Regel PR 16 

Wird in einem Paket ein Datentelegramm empfan- 
gen, wird erst auf das Ende des Pakets gewartet, um 35 
einen kompletten Datensatz zu empfangen, (ggf. 
weiteres Datentelegramm im Paket) um diesem 
durch Eintragen in den Datenempfangspuffer kom- 
plett an die datenverarbeitenden Funktionen der 
Station weiterzugeben. 40 
D, h. ein xREN darf erst gesendet werden nach dem 
kompletten Empfang eines Datentelegramme ent- 
haltenden Pakets und nach dem Auslesen dieser 
Datentelegramme aus dem Datenempfangspuffer 
durch die datenverarbeitenden Funktionen der Sta- 45 
lion. ( Vgl. Daten-Regeln, Abschn. 4.7.1 ) 

4.73 Backup-Regeln 

Das backup ist Teil des Kontextes einer Station. 50 
(Vergl. Kontext der Station, Abschn. 43) 

Folgende Regeln gelten fur die Referenzierung des 
backups. 

- Backup-Regel BR 1 55 
Initiierung. 

Das backup wird bei Start einer Station als leer 
initialisiert. 

- Backup-Regel BR 2 

Aktion bei Senden eines Telegramms. 60 
Jedes original (ersimalig, d. h. nicht wiederholt) zu 
sendende Datentelegramm und Synchronisation- 
stelegramm, auDer xREL, wird in das backup iiber- 
nommen und dabei an das aktuelle Ende des bak- 
kup plaziert. Die Folgekennung ist in den backup- 65 
Telegrammen nicht enthalten, da vor oder bei wie- 
derholtem Senden eveniuell zwischenzeitlich neue 
Telegramme ins backup aufgenommen wurden und 



alle Telegramme als elWmederholtes Paket gesen- 
det werden. Die Prufsumme eines Telegramms ist 
ebenfalls nicht im backup enthalten, da sie wegen 
der Polaritat der Folgekennung variieren kann, d. h. 
beim wiederholten Senden falsch sein kann. 

- Backup-Regel BR 3 

Aktion nach Empfang von xACK (varec). 
Von der Partnerstation wurden varec Telegramme 
valide empfangen. das letzte empfangene Tele- 
gramm war das letzte im Paket (Folgekennung). Es 
wurde also ein Paket komplett empfangen. 
Sie quittiert dies mittels Senden des Telegramms 
xACK (varec). 

Nach Empfang von xACK (varec) werden die varec 
altesten Telegramme aus dem backup geloscht 

- Backup-Regel BR 4 

Aktion nach Empfang von xREL (varec) (civtel). 
Von der Partnerstation wurden vor Empfang einer 
Storung varec Telegramme valide empfangen. Es 
wurde also ein Paket nicht komplett empfangen. 
Sie fordert die restiichen Telegramme dieses Pa- 
kets mittels Senden des Telegramms xREL (varec) 
(civtel) an. 

Nach Empfang des Telegramms xREL (varec) (civ- 
tel) wird, falls nicht mehr als varec Telegramme im 
backup stehen, das backup nicht referenziert (Wie- 
derholung ist nicht moglich/notig). 
Falls mehr als varec Telegramme im backup stehen. 
werden, bis auf die altesten varec Telegramme im 
backup, alle Telegramme (also Datentelegramme 
und Synchronisationstelegramme) aus dem backup 
reihenfolgerichtig (Reihenfolge des Eintragens in 
das backup) wiederholt gesendet Neue zwischen- 
zeitlich in das backup aufgenommene Telegramme 
werden damit ebenfalls wiederholt gesendet Alle 
diese Telegramme bilden ein Paket (Folgeken- 
nung). Kein Telegramm wird im backup geloscht 

- Backup-Regel BR 5 

Aktion nach Empfang von xxLIF. xRINI, xREN 
oder Datentelegrammen: 

Diese empfangenen Telegramme bewirken keine 
Anderung im backup. 

4.8 Fehlerbehandlung bei gestorter Obertragung 

Eine Storung in der Obertragung zwischen beiden 
Stationen U und 1 liegt in den nachfolgenden Fallen vor. 
Diese Obertragungsfehler werden in den Empfangern 
der Obertragungseinrichtungen erkannt Nach Feststel- 
lung eines Fehlers werden die (ggf.) weiteren Zeichen 
dieses Telegramms bzw. Pakets nicht mehr empfangen 
(Deaktivierung des Empfangers). 

Folgende Reaktionen, nachstehend naher erlautert, 
sind nach Erkennung eines Fehlers moglich: 

- Wiederholungsprufung(WHP)oder 

- Neustart der Obertragung (NST). 

Eine Wiederholungsprufung erfolgt nach dynami- 
schen Fehlern, die durch die Systemumgebung bedingt 
sind. 

Ein Neustart der Obertragung erfolgt nach statischen 
Fehlern, die durch fehlerhafte Implementierung der Re- 
geln innerhalb der Obtragungseinrichtung oder durch 
Fehlfunktion der Obertragungseinrichtung bedingt sind. 

Die Reaktionen auf mogliche Fehler sind wie folgt 
festgelegt: 
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Fehler interface (parity, frame, overrun): WHP 

Fehler Priifsumme: WHP 

Fehler timeout im Paket: WHP 

Fehler xRELempfangen: WHP 

Fehler Paket Lange: NST 5 

Fehler unerwartetes xREN: NST 

Fehler unerwartetes lALIF: NST 

Fehler unerwartetes xREL: NST 

Fehler unerwartetes Datentelegramm: NST 

Fehler CI VSTA Oberlauf: NST lO 

Fehler timeout fur lALIF: NST 

Fehler timeout fur IREN nach URINI: NST 

Fehler invalides VAREC in xREL, xACK: NST 



14 



4.8.1 Beschreibung moglicher Fehler 



15 



- Fehler interface (parity, f rane, overrun) 
Beim Empfang jedes Zeichens eines Telegramms 
wird der interface Status uberpruft, urn ein ver- 
falschtes Zeichen zu erkennen. 20 

- Fehler Priifsumme 

Jedes Telegramm enthalt eine Prufsumme. Wird ein 
Telegramm mit verfalschter Prufsumme empfan- 
gen. liegt ein Fehler vor. 

- Fehler timeout im Paket 25 
Dieser Fehler liegt vor, falls nach dem Beginn des 
Empfangs eines Paketes innerhalb eines bestimm- 
ten Zeitbereichs (timeout) nicht das letzte Tele- 
gramm (Folgekennung) dieses Pakets empfangen 
wurde. 30 

- Fehler xRELempfangen 

Der Empfang eines Telegramms xREL bedeutet, 
dafi die Partnerstation eine Storung empfangen 
und daraufhin ein wiederholtes Senden angefordert 
hat. Der Empfang eines Telegranrims xREL bedeu- 35 
tet somit. daB ein Fehler in der Obertragung auf- 
trat. 

- Fehler Paket Lange 

Beinhaltet ein Paket mehr Datentelegramme als in 
den Datenempfangspuffer eingeschrieben werden 40 
kann. liegt ein Fehler vor. 

- Fehler unerwartetes xREN 
Wird nach dem Empfang eines Telegramms xREN 
ein weiteres xREN empfangen. bevor ein Paket mit 
mindestens einem Datentelegramm gesendet wur- 45 
de, liegt ein Fehler vor. 

- Fehler unerwartetes lALIF 
Wird in der Station U (master) nach dem Empfang 
eines lALIF ein weiteres lALIF empfangen, bevor 
ein URLIF gesendet wurde, liegt ein Fehler vor. 50 

- Fehler unerwartetes xREL 

Wird nach dem Empfang eines Telegramms xREL 
ein weiteres xREL empfangen, bevor das Paket 
wiederholt gesendet wurde, liegt ein Fehler vor. 

- Fehler unerwartetes Datentelegramm 55 
Wird nach dem Empfang eines Paketes mit minde- 
stens einem Datentelegramm ein weiteres Paket 
mit mindestens einem Datentelegramm empfan- 
gen, bevor ein xREN bzw. xREL gesendet wurde, 
liegt ein Fehler vor. 60 

- Fehler CI VSTA Oberlauf 

Werden bei langerer Storung der Obertragung nur 
noch xREL ausgetauscht, erreicht CIVSTA in einer 
Station seinen maximal zulassigen Wert, der frei 
def iniert sein kann, 65 
Bei Erreichen dieses Wertes erscheint ein weiteres 
Senden von xREL nicht sinnvoll. 

- Fehler timeoul fur lALIF 



Wird in Station UXnTaster) nach Senden eines Tele- 
gramms URLIF nicht rechtzeitig ein lALlF emp- 
fangen, liegt ein Fehler vor. Der zulassige timeout 
kann frei bestimmt werden. 

- Fehler timeout fur IREN nach URlNl 

Wird innerhalb der Initiierung der Obertragung in 
Station U nach Senden eines URINI nicht rechtzei- 
tig ein IREN empfangen. liegt ein Fehler vor. Der 
zulassige timeout kann frei bestimmt werden. 

- Fehler invalides VAREC in xREL, xACK 
VAREC ist in den Telegrammen xREL und xACK 
enthalten. (Vergl. Kontext der Station und Proto- 
koU-Regeln. Abschn. 43 und 4.72), 

Wird ein Telegramm xREL (varec) (civtel) empfan- 
gen mit (varec) groQer als die Anzahl der Tele- 
gramme im backup (in Partnerstation mehr Tele- 
gramme erfolgreich empfangen als gesendet) liegt 
ein Fehler vor. 

Wird ein xREL (varec) (civtel) empfangen mit (va- 
rec) gleich der Anzahl der Telegramme im backup, 
liegt kein Fehler vor (keine Wiederholung moglich/ 
notig). 

Dieser Fall ist zulassig aufgrund der Protokoll-Re- 
geln fur den Telegramm- Abl^uf bei zeitlich mehrf a- 
chen hintereinander auftretenden Storungen. 
Wird ein xACK (varec) empfangen mit (varec) = 0 
(Quittierung fur Anzahl valider empfangene Tele- 
gramme tel = 0) Oder mit (varec) groBer als die An- 
zahl der Telegramme im backup (mehr Telegram- 
me erfolgreich von der Partnerstation empfangen 
als gesendet), liegt ein Fehler vor. 

4.8^ Wiederholungsprufung 

Als Wiederholungsprufung wird die Entscheidung be- 
zeichnet. ob nach Feststellung einer Storung innerhalb 
der Obertragung (dynamischer Fehler) ein wiederholtes 
Senden von der Partnerstation anzufordern ist (durch 
Senden von xREL) oder ob ein Neustart der Obertra- 
gung einzuleiten ist, 

Eine Wiederholungsprufung erfolt nach jedem Inkre- 
ment von CIVSTA (vergl. Protokoll-Regeln. Abschn. 
4J2). 

Erreicht CIVSTA in einer Station seinen Maximal- 
wert (vergl. Fehler CIVSTA Oberlauf, Abschn. 4.8.1), 
wird dies als nicht korrigierbare'r Fehler bewertet und 
es erfolgt ein Neustart der Obertragung. 

Hat CIVSTA in einer Station seinen Maximalwert 
noch nicht erreicht, wird ein wiederholtes Senden von 
der Partnerstation angefordert 

Eine Wiederholungsprufung erfolgt auch nach jedem 
Empfang eines 

- durch interface-Fehler verfalschten Tele- 
gramms, 

— durch Prufsummen-Fehler verfalschten Tele- 
gramms. 

— timeout im Pakeu 

- xREL 

durch Referenzierung einer Semaphore. 

Diese Semaphore dient zur Erkennung und zum Ab- 
bruch von fehlerhaften Endlosschleifen in der Obertra- 
gung (z. B. permanenter Prufsummen-Fehler im wieder- 
holten Telegramm) oder sehr haufig verfalschter Ober- 
tragung (z. B. Prufsummen-Fehler nur in jedem original, 
also nicht wiederholt gesendeten Telegramm). 

Die Semaphore, also ein Zahler der inkrementiert und 
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dekrementiert werden kann. existiert in j^r Station. 
Diese Semaphore wird beim Start der Station auf einen 
b'estimmten Wert initialisiert (z. B.21). 

In der Wiederholungsprufung wird die Semaphore 
n-mal (Dekrementalwert, z. B. zwei) dekrementiert Er- 5 
reicht sie dabei den Wert Null oder kleiner Null, wird 
dies als nicht korrigierbarer Fehler bewertet und es er- 
folgt ein Neustart der Obertragung. Erreicht sie dabei 
nicht den Wert Null oder kleiner Null, wird gemaB den 
Protokoll-Regeln reagiert, d. h. es erfolgt kein Neustart 10 
der Obertragung. 

Nach jedem valide (unverfalscht) empfangenen Paket 
wird die Semaphore n-mal (Inkrementalwert, z, B. eins. 
muB ideiner sein als Dekrementalwert) inkrementiert, 
kann jedoch nicht groBer werden als ihr Initial wert 1 5 

Die Dimensionierung des Maximalwertes von CIV- 
STA und der Semaphore bezuglich Initialwert, Inkre- 
mentalwert und Dekrementalwert ist frei definierbar 
und bestimmt durch die im Storungsfall erlaubte Anzahl 
von Telegramm-Wiederholungen den Zeitraum. fur den 20 
eine gestorte Obertragung toleriert wird 

4.83 Neustart der Obertragung 

Als Neustart der Obertragung wird der Start einer 25 
Station nach einem dort festgestellten nicht korrigierba- 
ren Fehler bezeichnet 

Der Start einer Station wurde bereits beschrieben. 
(Vergl, Initiierung der Obertragung, Abschn, 43) Wird 
beim Start (oder Neustart) einer Station innerhalb der 30 
Initialisierungsphase im master nach Senden von URI- 
NI ein I REN vom slave nicht rechueitig oder in valide 
(verfalscht) empfangen, kann die Obertragung nicht ge- 
startet werden. 

Der master sendet danach solange zyklisch URLIF. 35 
bis er von slave IALIF(z. B. nach Zuschalten der vorher 
unterbrochenen Obertragungsleitung) oder IRINI 
(nach Start des slave) empf angt 

Danach wird wieder die Initialisierung der Obertra- 
gung durchgefiihrt. 40 

5.0 Exemplarische Darstellung der Obertragung 

Zur exemplarischen Darstellung der Obertragung ist 
in Fig. 3.1 bis 3.4 der zeitliche Ablauf einer Obertragiing 45 
in vier Teilen eines Obertragungsdiagramms gezeigt 
Eine erganzende Legende ist in Fig. 2 enthalten, 

Nachfolgend ist dieses Obertragungsdiagramm durch 
die Zuordnung der entsprechenden Regeln (vgl. Ober- 
tragungs-Regeln. Abschn. 4.7) schrittweise erlautert 50 

Dabei bedeutet ''Zn" (Zeit n) die zeitliche Skalierung 
innerhalb der einzelnen Teile des Obertragungsdia- 
gramms und "U" bzw. T die Namen der beteiligten 
Stationen. FQr die Darstellung der Telegramme im bak- 
kup stellt "xACKn" eine Kurzform dar fur "xACIC (va- 55 
rec)" mit n = (varec), also dem VAREQ der in das gesen- 
dete Telegramm x ACIC eingeschrieben wurde. 

Datentelegramme sind nur innerhalb jedes Teils des 
Obertragungsdiagramms fortlaufend durchnumeriert 
("UDn"/lDn"). 60 

5.1 Obertragungsdiagramm Teil I (Fig. 3.1) 



Alle Telegramme innerhalb dieses Teils werden vali- 
de empfangen. 65 

Bei ZO werden beide Stationen eingeschaltet, Dieser 
Erstanlauf bedeutet den Start beider Stationen. GemaB 
PR 3 initiiert jede Station ihren Kontext (BR I). Bei Zl 



sendet Station U URINI un^Wf*eibt dieses Telegramm 
in sein backup (PR 5, BR 2). Station I zahlt nach Emp- 
fang von URlNl dieses Telegramm in VAREC (PR 6) 
und antwortet, da sie ein komplettes Paket empfangen 
hat, sofort mit lACKl (bedeutet lACK (varec= 1)) (PR 
4), ubernimmt es ins backup (BR 2, PR 5), loscht seinen 
VAREC (PR 4) und sendet bei Z3 IREN (vergl. Initiie- 
rung der Obertragung), welches auch in das backup 
ubernommen wird (BR 2). Die beiden von I gesendeten 
Telegramme werden hier nicht innerhalb des gleichen 
Pakets gesendet, da zum Zeitpunkt des Sendens von 
IACK.1 die Initiierung der datenverarbeitenden Funk- 
tionen (Einrichtungen) der Station I noch nicht abge- 
schlossen war. welche von diesen erst spater der Ober- 
tragungseinrichtung signalisiert wurde. 

Das in Station U empfangene lACKl wird in VAREC 
gezahlt (PR 6) und genau ein Telegramm (entsprechend 
varec«=l aus Telegramm lACKl) wird im backup ge- 
loscht(PR8.BR3). 

Das bei Z4 in Station U empfangene IREN wird in 
VAREC gezahlt (PR 6) und lost aufgrund PR 4 das 
Senden von UACK (varec) (also UACK2) und das L6- 
schen von VAREC aus. UACK2 wird in das backup 
ubernonmen (PR 5), Station U darf nuit nach Empfang 
von IREN Datentelegramme senden. es jiegen aber mo- 
mentan keine vor. 

Station U sendet nun UREN (vergl. Initiierung der 
Obertragung). das ebenfalls ins backup ubernommen 
wird (PR 5). Beide Telegramme bilden hier jeweils ein 
eigenes paket, d. h, in beiden ist die Folgekennung ge- 
loscht 

Bei Z5 loscht der Empfang von UACK2 in Station 1 
zwei Telegramme aus dem backup (PR 8), hachdem die- 
ses Telegramm in VAREC gezahlt wurde (PR 6). Nach 
Empfang von UREN. in VAREC gezahlt (PR 6), wird 
aufgrund von PR 4 ein IACK2 gesendet, das in das 
backup iibemommen wird (PR 5). 

Datentelegramme durfen nach Empfang von UREN 
von Station I gesendet werden, es liegen aber momen- 
tan keine vor. 

Bei Z7 wird IACK2 in Station U empfangen und in 
VAREC gezahlt (PR 6). Es loscht zwei Telegramme aus 
dem backup (PR 8). 

Nun ist die Initiierung abgeschlossen. beide Stationen 
durfen Datentelegramme senden. Die Regeln aus PR 14 
sind erfullt 

Bei Z8 beginnen beide Stationen spontan Datentele- 
gramme zu senden, wobei in Station I bei Zl 1 das Ende 
des empfangenen Pakets (Folgekennung) erkannt wird, 
so daQ das notige Telegranm I ACK3 (PR 4) noch an das 
gesendete Paket (bestehend aus den Datentelegrammen 
ID1-ID4) angehangt werden kann. 

Bei Z12 empfangt Station U das Ende dieses Pakets 
und antwortet seinerseits mit UACIC6, In beiden Statio- 
nen konnen die empfangenen Datentelegramme noch 
nicht gespeichert werden. somit wird noch kein xREN 
gesendet (DR 1). 

Die Regeln aus PR 14 sind erfullt 

Aufgrund PR 7 wird CIVSTA immer auf dem Wert 
Null gehalten. 

Aufgrund PR 12 ist der Merker WRR immer geloscht. 

52 Obertragungsdiagramm Teil 2 (Fig. 32) 

Da fiir eine langere Zeit in Station U kein Telegramm 
empfangen wurde, sendet Station U bei Zl URLIF 
(vergl. lifeloop). Gleichzeitig konnten in Station 1 die 
zuletzt empfangenen Datentelegramme gespeichert 
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werden, so daC Station I nun IREN sendet (DR 2), wel- 
ches aber in Station U verfalscht empfangen wird (PR 
13). Station U inkrementiert CIVSTA, deaktiviert seinen 
Empfanger und startet sein delay. 

In Station I wird bei Z2 URLIF valide empfangen und 
mit IACIC2. lALIF in einem Paket beantwortet (PR 4), 
welches aber in Station U nicht empfangen wird, 

Nach Ablauf seines delay bei Z6 sendet Station U 
UREL (PR 13). der Marker WRR wird gesetzt (PR 11). 
UREL wird nicht in das backup ubernommen (PR 5). 

Station I empfangt bei Z7 UREL (varec^O) (civ- 
tel = l). Es wird nicht in VAREC gezahit (PR 6). Da 
CIVSTA«0 und (civtel = l) ist. gilt PR 103 und BR 4. 
Alle Telegramme aus dem backup werden wegen (va- 
rec = 0) wiederholt gesendet VAREC wird beim wieder- 
holten Senden von IACK2 nicht geloscht (PR 4). 

Wahrend in Station U die wiederholt gesendeten Te- 
legramme empfangen werden. sendet Station U bei Z8 
spontan UREN. da die zuletzt empfangenen Datentele- 
gramme nun gespeichert werden konnten (DR 2). Sta- 
tion I darf nun wieder Datentelegramme senden (DR 1). 
Aufgrund von PR 4 beantwortet Station I das empfan- 
gene Paket (mit dem alleinigen Telegramm UREN) mit 
lACKl. das in die gerade noch laufende Telegramm- 
Wiederholung als letztes Telegramm eingebettet wird 

Bei ZIO loscht Station U nach dem Empfang des Pa- 
kets seinen Merker WRR (PR 12) und quittiert den En- 
pfang des Pakets durch Senden von UACK4. Als weite- 
res Paket sendet Station U daraufhin das Datentele- 
gramm UDl (DR 1), welches bei Z12 in Station I ver- 
falscht empfangen wird (PR 13). CIVSTA in Station I 
wird inkrementiert 

Nach seinem delay setzt Station I seinen Merker 
WRR und sendet bei Z13 IREL (varec«*l) (civtel«=l), 
welches in Station U ebenfalls verfalscht empfangen 
wird Station U inkrementiert seinen CIVSTA und star- 
tet sein delay, sendet bei Z15 UREL (varec = 0) (civ- 
tel = 1) und setzt seinen Merker WRR- 

Bei Z16 empfangt Station I UREL (varec = 0) (civ- 
tel = l) valide. Da CIVSTA « (civtel) - 1 gilt PR 10.1. 
CIVSTA wird inkrementiert, da es vorher grofler als 
Null war. Eine Telegramm- Wiederholung ist nicht mo- 
gich, da das backup in Station I leer ist Ein IREL (va- 
rec=l) (civtel = 2) wird gesendet Der Merker WRR 
wird gesetzt (er war seit dem Senden von IREL bei Z13 
schon gesetzt). 

Bei Z17 empfangt Station U das Telegramm IREL 
(varec = 1 ) (civtel = 2). Da CIVSTA kleiner als (civtel) ist. 
gilt PR 103. 

Da mit IREL ein komplettes Paket empfangen wurde. 
wird der Merker WRR geloscht nach Anwendung der 
Regel PR 10.3 (PR 12). 

CIVSTA wird geloscht, alle Telegramme aus dem 
backup, aber nicht die altesten (varec) Telegramme wer- 
den aus backup wiederholt gesendet d h. das von U bei 
ZIO original gesendete UACK4 wird nicht wiederholt 
gesendet sondern nur das bei Zll original gesendete 
UDL Da der Merker WRR noch gesetzt ist (PR 12), muQ 
auch ein UREL gesendet werden (PR 103). 

Der Merker WRR wird jetzt nach erfolgter Anwen- 
dung von PR 103 g^eloscht infolge des Sendens von 
IREL bei ZlSgemaB PR 11 aber wieder gesetzt 

Es gilt die in PR 9 festgelegte Reihenfolge des Sen- 
dens, d h. zuerst UDl. dann UREL. Beide gesendeten 
Telegramme bilden ein Paket 

Bei Z18 wird UDl empfangen als nicht letztes Tele- 
gramm eines Paketes (PR 16), CIVSTA wird aufgrund 
PR 7 geloscht. 



GemaB PR 4 muB der Empfang des kompletten Pa- 
kets durch Senden von lACK quittiert werden. 

Bei Empfang von UREL (varec = 0) (civtel = 0) bei 
Z19 gilt Regel PR 10,1. da CIVSTA- (civtel) = 0. Da 
5 CIVSTA schon Null ist wird es nicht inkrementiert 

Aufgrund von PR 12 wird Merker WRR in Station I 
bei Z19 geloscht 

Ein Senden aus dem backup erfolgt nicht, da das bak- 
kup leer ist Es wird kein IREL gesendet (PR 10.1). Jetzt 
10 wird als Quittierung IACK2 gesendet 

Da das empfangene UDl sofort gespeichert werden 
konnte, wird innerhalb des Pakets sofort IREN gesen- 
det 

Dieses Paket wird in Station U valide empfangen, 
15 Merker WRR wird geloscht (PR 12) und bei Z21 der 
Empfang des Pakets durch Senden von UACK2 quit- 
tiert 

Die Regeln aus PR 14 sind erfullt 
Beide Stationen haben ein xREN empfangen und dur- 
20 fen Datentelegramme senden. 

53 Obertragungsdiagramm Teil 3 (Fig. 33) 

Beide Stationen senden drei Datentelegramme. wo- 
25 bei bei Z3 UD2 in Station I verfabcht empfangen wird 
(PR 13). 

Wahrend des delay in Station I kann Station I weiter- 
hin Telegramme (z. B, ID2) senden. 

Nach Ende des delay bei Z5 wird IREL (varec -2) 
30 (civtel = 1) gesendet und zwar eingebettet in das gerade 
noch laufende Senden der Datentelegramme (PR 1) ge- 
maBPR9. 

Bei Z6 empfangt Station U dieses IREL (varec -=2) 
(civtel =1) als nicht letztes Telegramm des Pakets (PR 
35 10). Weil CIVSTA kleiner als (civtel) ist gilt PR 103. 
Merker WRR ist in Station U gesetzt 

Station U sendet wiederholt UD2 und UD3 aus dem 
backup. Den Empfang des kompletten Pakets quittiert 
Station U mittels Senden von UACK3. welches noch in 
40 das Paket mit den wiederholten Datentelegrammen auf- 
genommen werden kann, da der Empfang des Pakets 
von Station I friiher beendet ist als das wiederholie 
Senden aus Station U. UACK3 wird gemaQ PR 9 inner- 
halb des Pakets nach den Telegrammen aus dem backup 
45 eingebettet 

Bei Z9 hat Station I das komplette Paket empfangen 
und quittiert es durch Senden von IACK5. 

bei ZIO sendet Station I nach Speichern der empfan- 
genen Datentelegramme IREN, bei Zll sendet Station 
50 U nach Speichern der empfangenen Datentelegramme 
UREN. Diese beiden Telegramme werden jeweiis ver- 
falscht empfangen, beide Stationen starten ihr delay. 

Das delay in Station U ist fruher beendet als das delay 
in Station I (vergl. Bemerkung zu PR IOjc). 

UREL (varec=l) (civtel'=l) kann in Station I nicht 
empfangen werden, da in Station I wahrend des noch 
laufenden delay der Empfanger deaktiviert ist Nach 
Ende des delay in Station I sendet Station 1 bei Z14 
IREL (varec = 0) (civtel 1), das in Station U verfalscht 
empfangen wird Nach Ende des darauf folgenden delay 
sendet Station U bei Z16 UREL (varec - 1) (civtel = 2), 
Nach Ende der zeitweiligen Obertragungsstorung emp- 
fangt Station bei Z17 UREL (varec =1) (civtel = 2). Da 
jetzt CIVSTA kleiner als (civtel) ist gilt PR 10.3, CIV- 
65 STA wird geloscht Merker WRR ist gesetzt (PR 12), 
Nach dem notigen wiederholten Senden von IREN aus 
dem backup wird im gleichen Paket ebenfalls IREL (va- 
rec = 0) (civtel - 0) gesendet (PR 1 03, PR 9). 
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Nach dem Empfang dieses Pakets bei ^^Pt Station 
U (PR 15) gilt Regel PR 10.1. Station V sendet wieder- 
hdlt UREN aus seinem backup und quittiert den Emp- 
fang des Pakets durch Senden von UACK2. 

Nach dem Empfang dieses Pakets bei Z21 in Station I 5 
(PR 15) quittiert Station I den Empfang dieses Pakets 
durch Senden von I ACK2. 

Die Regein aus PR 14 sind erfuUt 
Beide Stationen haben ein xREN empfangen und dur- 
fen Datentelegramme senden. 10 

5.4 ObertragungsdiagrammTeil 4 (Fig. 3.4) 



bei Zl 5 quittiert Station U m^^RCK3. 

Die Speicherungdes Datentelegramms ID2 in Station 
U verzogert sich. so daB Station U das Tetegramm 
UREN erst bei Z17 senden kann (PR 16, DR 2). Es stelit 
somit ein eigenes Paket dar. 

Nach Empfang dieses Pakets in Station I bei Z18 
quittiert Station I mit IACIC2. 
Die Regein aus PR 14 sind erfullt 
Beide Stationen haben ein xREN empfangen und dur- 
fen Datentelegramme senden. 



Alle Telegramme innerhalb dieses Teils werden vali- 
de empfangen. 15 

Station 1 fordert ihre Initialisierung durch Senden von 
IRINI an. Die Ursache fur diesen Initialisierungswunsch 
ist hier nicht dargestellt, sie ist im Start oder Neustart 
der Station begriindeL 

Station U beam wort et den Empfang von IRINI mit 20 
Senden von UACK2 und URINI (vergl. Initiierung der 
Obertragung). 

Nach Empfang von URINI in Station I bei Z3 quittiert 
diese mit IACIC2 und signalisiert durch Senden von 
IREN, daB sie wieder Datentelegramme empfangen 25 
kann. 

Station U ihrerseits sendet nach Empfang dieses 
IREN bei Z6 die Quittierung UACK2 und ebenfalls 
UREN. urn der Station I zu signalisieren. daB auch diese 
wieder Datentelegramme senden darf. Gleichzeitig lie- 30 
gen bei Z6 in U schon zwei Datentelegramme (UDl, 
UD2) zum Senden vor. Aufgrund PR 1 und PR 9 bilden 
alle diese zu sendenden Telegramme ein Paket, d. h. zu- 
erst wird UACK gesendet als Quittierung fur den Emp- 
fang des kompletten Pakets von Station I, dami UREN 35 
und UDl. 

Vor Senden von UD2 hat U bei Z9 ein Datentele- 
gramn IDl empfangen, das spontan von Station I gesen- 
det wurde. Da dieses Datentelegramm IDl ein komplet- 
tes Paket darstellt, gilt bei dessen Empfang in Station U 40 
die Regel PR 16. 

Da IDl in Station U sofort gespeichert werden kann 
(DR 2), muB Station U ein UREN senden. Ebenfalls muB 
Station U ein.UACK als Quittierung des Empfangs des 
kompletten Pakets (also wegen IDl) senden. 45 

Diese noch zu sendenden Telegramme werden in das 
gerade gesendete Paket eingebettet, so daB gemafi PR 9 
diese Telegramme in der Reihenfolge UACKl. UREN, 
UD2 gesendet werden. 

Diese Obertragungsphase zeigt, daB ein Paket, und 50 
somit auch das backup, mehrere xREN und xACK ent- 
halten kann. 

Nach Empfang von UREN in Station I (nicht letztes 
Telegramm im empfangenen Paket) bei ZU (PR 15, DR 
1) sendet I spontan ein weiteres Datentelegramm ID2 55 
bevor es das Ende des Empfangs des kompletten Pakets 
von U erkannt hat. Den kompletten Empfang des Pakets 
von Station U quittiert Station I durch Senden von 
IACK6 bei Z13. Da alle von Station U empfangenen 
Datentelegramme (UDl, UD2) zwischenzeitlich schon eo 
gespeichert werden konnten (PR 16, DR 2) sendet Sta- 
tion 1 das Telegramm IREN. Fur die Reihenfolge des 
Sendens von IACK6 und IREN gilt die Regel PR 9, nicht 
aber fur ID2, da das Senden dieses Telegramms schon 
durch den Empfang von UREN bei Zl 1 ausgelost wurde 65 
und es zu Senden begonnen wurde vor Ende des Emp- 
fangs des kompletten Pakets von U. 

Nach Empfang des kompletten Pakets in Station U 



Patentanspruche 

1. Verfahren zur Obertragung von Datentelegram- 
men zwischen zwei Stationen uber eine Obertra- 
gungsstrecke mittels einer Obertragungseinrich- 
tung, die fiir gieichzeitiges Senden und Empfangen 
in beiden Richtungen eingerichtet ist, wobei nach 
einer Obertragungsstorung mit Hilfe von Synchro- 
nisationstelegrammen eine folgerichtige Wieder- 
aufnahme des Austauschs von Datentelegrammen 
sichergestellt wird, dadurch gekennzeichnet, daD 
fur die Obertragung Pakete gebildet werden, die 
aus einem oder mehreren Telegrantmen bestehen, 
wobei es sich um Datentelegramme, Synchronisa- 
tionstelegramme oder um eine Folge von Daten- 
und Synchronisationstelegramme handeln kann 
und daB in ein Paket, dessen Sendung noch nicht 
abgeschlossen ist, Synchronisationstelegramme im 
Bedarf sf all eingef iigt werden. 

2. Verfahren nach Anspruch 1, gekennzeichnet 
durch eine Paketbildung mit Hilfe einer Folgeken- 
nung, die in den Telegrammen eines Pakets mit 
Ausnahme des letzten Telegramms des Pakets ge- 
setzt ist 

3. Verfahren nach Anspruch 1 oder 2, dadurch ge- 
kennzeichnet, daB zur Initialisierung der Obertra- 
gung eine master-slave- RoUenverteilung zwischen 
den beiden Stationen eintritt, wobei die master-Sta- 
tion zunachst fur die Ablaufsteuerung notwendige 
und gespeicherte Merker und Zahler in definierter 
Weise setzt und anschlieBend die slave-Station mit 
einem festgelegten Synchronisationstelegramm 
auffordert. ihrerseits mit einem Synchronisationste- 
legramm ihre Empfangsbereitschaft zu melden, 
worauf die slave-Station ebenfalls Merker und 
Zahler in einen festgelegten Zustand bringt und die 
Empfangsbereitschaft durch Sendung des angefor- 
derten Synchronisationstelegramms bestatigt 

4. Verfahren nach Anspruch 3, dadurch gekenn- 
zeichnet, daB zur KontroUe der Funktionsfahigkeit 
der Ubertragungseinrichtung in Obertragungspau- 
sen mit definierter Mindestdauer eine master-sla- 
ve- RoUenverteilung zwischen den beiden Stationen 
eintritt und die master-Station mit einem festgeleg- 
ten Synchronisationstelegramm die slave-Station 
auffordert mit einem ebenfalls festgelegten Syn- 
chronisationstelegramm ihre Funktionsfahigkeit zu 
bestatigen. 

5. Verfahren nach Anspruch 3 oder 4. dadurch ge- 
kennzeichnet, daB das Eintreffen eines Antwort- 
Synchronisationstelegramms innerhalb einer defi- 
nierten Dauer in der master-Station uberwacht und 
fur eine definierte Fehlerbehandlung ausgewertet 
wird. 

6. Verfahren nach einem der vorstehenden Anspru- 
che, dadurch gekennzeichnet, daB nachstehende 
Synchronisationstelegramme verwendet werden: 
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a) Anforderung des Sendens weiterer Datente- 
legramme(UREN,IREN); 

b) Anforderung des wiederholien Sendens der 
zuletzt gesendeten Telegranme (UREL, 
IREL); dieses Telegramm enthalt Kennungen 5 
(VARECCIVTEL); 

c) Aufforderung (URLIF) von Station U an 
Station I ein Lebenssignal (I ALIF) zu senden; 

d) Aufforderung (URINI) der Station U an 
Station eine Initialisierung in Station I durch- 10 
zufuhren; 

e) Anforderung (IRINI) eines Initialisierungs- 
telegrammes (URINI) durch die Station I an 
Station U; 

0 Quittierung (UACK, lACK) eines fehlerfrei 15 
und vollstandig empfangenen Pakets; dieses 
Telegramm enthalt eine Kennung (VAREC). 

7. Verfahren nach Anspruch 6. dadurch gekenn- 
zeichnet, daB nachstehende stationstypische Mar- 
ker und Zahler, die als Kontext einer Station be- 20 
zeichnet sind, verwendet werden: 

a) ein Speicherbereich (backup) fur gesendete 
Telegramme, der zur Telegrammwiederho- 
lung genutzt wird, 

b) ein erster Zahler (VAREC) fiir die Anzahl 25 
der unverfalscht empfangenen Telegranme 
seit Senden des letzten Synchronisationstele- 
gramms zur Quittierung (UACK, I ACK), 

c) ein zweiter Zahler (CIVSTA) fur die Anzahl 
der verfalscht empfangenen Telegramme und 30 

d) ein Merker (WRR). der angibt. ob nach dem 
Senden eines Anforderungstelegramms fur 
wiederholtes Senden (UREL, IREL) der Emp- 
fang aller Telegramme. deren wiederholtes 
Senden angefcrdert wurde, abgeschlossen ist 35 

8. Verfahren nach Anspruch 7. dadurch gekenn- 
zeichnet, daB das Obertragungsverfahren als Sum- 
me einzelner Regeln defmiert ist, wobei definiert 
sind: 

a) Daten- Regeln fur die Obertragung von Da- 40 
tentelegrammen, 

b) backup-Regeln zur Steuerung der Speiche- 
rung von Telegrammen bis zum erfolgreichen 
AbschluB der Obertragung von Paketen, und 

c) ProtokoU-Regeln fur die Abfolge von Daten 45 
und Synchronisationstelegrammen sowie fur 
die Definition der Art der benutzten Synchro- 
nisatinstelegramme und der in den Stationen 
gespeicherten. als Kontext bezeichneten Mer- 
ker und Zahler. 50 

9. Verfahren nach Anspruch 8, dadurch gekenn- 
zeichnet, daB als Daten-Regein definiert sind: 

a) Datentelegramme werden, sobald sie in ei- 
nem Datensendepuffer vorliegen, erst dann 
gesendet, nachdem zuvor ein Synchronisation- 55 
stelegramm (UREN. IREN) empfangen wurde. 
Alle Telegramme aus dem Datensendepuffer 
werden innerhalb eines Pakets gesendet 

b) Ein Synchronisationstelegramm (UREN, 
IREN) wird nach dem Empfang von Datente- 60 
legrammen in einem Datenempfangspuffer 
erst dann gesendet, wenn diese von den da- 
tentverarbeitenden Einrichtungen ausgelesen 
wurden; 

c) bei storungsfreier Obertragung werden Da- 65 
tentelegramme (UD, ID) und Synchronisation- 
stelegramme (UR-EN. IREN, UACK, lACK, 
URLIF, lALIF)ausgetauschl. 
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10. Verfahren n^lHT Anspruch 8 oder 9, dadurch 
gekennzeichnet, daB als backup-Regeln definiert 
sind: 

a) der Speicherbereich (backup) wird beim 
Start einer Station (U. I) als leer initialisiert; 

b) jedes original (d. h. nicht wiederholt) zu sen- 
dende Datentelegramm (UD, ID) und Syn- 
chronisationstelegramme (UACK, lACK, 
UREN. IREN, URLIF, lALIF. IRINI, URINI). 
mit Ausnahme der Wiederholungs-Anforde- 
rungstelegramme (UREL, IREL). wird in den 
Speicherbereich ubernommen und dabei an 
das aktuelle Ende des Speicherbereichs (bak- 
kup) plaziert; eine Folgekennung oder Pruf- 
summe wird nicht in den Speicherbereich (bak- 
kup) ubernommen; 

c) nach Empfang eines Quittierungstele- 
gramms (UACK, lACK) mit dem Wert (varec) 
des ersten Zahlers (VAREC) der Partnersta- 
tion als Kennung, werden die. bezuglich ihrer 
Anzahl dem Wert (varec) entsprechenden, "al- 
testen" Telegramme aus dem Speicherbereich 
(backup) geloscht; 

d) nach Empfang eines jViederholungs-Anfor- 
derungstelegramms (UREL. IREL) mit Ken- 
nungen (varec, civtel) wird nur dann wieder- 
holt gesendet, wenn die Anzahl der Telegram- 
me im Speicherbereich groBer ist als der Wert 
(varec) des ersten Zahlers (VAREC). der als 
Kennung im Wiederholungs-Anforderungste- 
legramm (UREL, IREL) enthalten ist, wobei, 
bis auf die altesten Telegramme in der Anzahl 
entsprechend dem Wert (varec), alle Tele- 
gramme, auch zwischenzeitlich neu in den 
Speicherbereich (backup) aufgenommene Te- 
legramme wiederhoU gesendet werden; kein 
Telegramm wird dabei geloscht; 

e) ein Empfang von Datentelegramm-Anfor- 
derungstelegranmen (UREN, IREN). Initiali- 
sierungstelegrammen (URINI, IRINI) und Le- 
benssignaltelegramme (URLIF, lALIF) sowie 
von Datentelegrammen (UD. ID) bewirkt kei- 
ne Anderung im Speicherbereich (backup). 

n. Verfahren nach einem der Anspruche 8 bis 10, 
dadurch gekennzeichnet, daB als Protokoll- Regeln 
definiert sind: 

a) Datentelegramme (UD, ID) und Synchroni- 
sationstelegramme (UREN. IREN. UACK, 
lACK, URLIF. lALIF, UREL. IREL) konnen 
innerhalb eines Pakets gemischt auf treten ; 

b) ein Synchronisationstelegramm zur Quittie- 
rung (UACK, lACK) dient nur zur Steuerung 
des Loschens des Speicherbereichs (backup); 

c) zur Initiierung des stationseigenen Kontexts 
nach einem Start der Stationen werden Zahler 
(VAREC. CIVSTA), Speicherbereich (backup) 
und Merker (WRR) zu Null gesetzt; 

d) ein originales Quittierungstelegramm 
(UACK, lACK), das den Wert (varec) des er- 
sten Zahlers (VAREC) enthalt, wird sofort 
nach fehlerfrei empfangenem Paket gesendet, 
wenn das Paket andere Telegramme als Quit- 
tierungstelegramme (UACK, lACK) oder An- 
forderungstelegramme (UREL, IREL) zur 
Wiederholung enthalt; nach dem Senden eines 
solchen originalen Quittierungstelegramms 
(UACK, lACK) wird der erste Zahler (VA- 
REC) auf Null gesetzt; nach dem Senden eines 
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Quittierungstelegramms (UACI^^CK) 
dem Speicherbereich (backup) wird der erste 
Zahler (VAREC) nicht auf Null gesetzL 

e) Jedes original gesendete Telegramm. auBer 
einem Anforderungstelegramn (UREL. IREL) 
zur Wiederholung, wird in den Speicherbe- 
reich (backup) geschrieben; 

f) jedes fehlerfrei (valide) empfangene Tele- 
gramm, auBer einem Anforderungstelegramm 
(UREU IREL) zur Wiederholung, wird mit 
dem ersten Zahler (VAREC) gezahlt; 

g) nach jedem fehlerfrei (valide) empfangenen 
Telegramm, auBer einem Anforderungstele- 
gramm (UREL, IREL) zur Wiederholung, wird 
der zweite Zahler (CIVSTA) auf Null gesetzi; 

h) nach Empfang eines Quittierungstele- 
gramms (UACK, lACK) mit dem Wert (varec) 
des ersten Zahlers (VAREC) der Partnersta- 
tion als Kennung, wird sofort, ohne auf das 
Ende des Pakets zu warten. eine Anzahl Tele- 
gramme, die dem Wert (varec) des ersten Zah- 
lers (VAREC) entspricht, aus dem Speicherbe- 
reich (backup) geloscht; 

i) falls mehrere Typen von Telegrammen kon- 
kurrierend gleichzeitig zum Senden anstehen, 
gilt folgende Reihenfolge: 

1. Telegramme aus dem Speicherbereich 
(backup) und zwar in der gespeicherten 
Reihenfolge. 

2. originale Quittierungstelegrsimme 
(UACK. lACK), 

3. originale Datentelegramm-Anforde- 
rungstelegramme (UREN, IREN), 

4. orginiale Wiederholungs-Anforde- 
rungstelegramme (UREL, IREL), 

5. originale Lebenssignal-Anforderungs- 
telegramme (URLIF, lALIF), 

6. originale Initialisierungstelegramm-An- 
forderungstelegramme (IRINI) und Initia- 
lisierungstelegramme (URINI). 

7. originale Datentelegramme (UD, ID); 
k) nach Empfang eines Wiederholungs-Anfor- 
derungstelegramms (UREL, IREL) mit einer 
Kennung (varec, civtel) wird nach gesonderten 
Regeln eine Telegramm- Wiederholung veran- 
laBt; 

I) nach jedem Senden eines Wiederholungs- 
Anforderungstelegramms (UREL, IREL) mit 
einer Kennung (varec, civtel) wird der Merker 
(WRR) gesetzt, der nach jedem Empfang eines 
kompletten Pakets auf Null gesetzt wird; 
m) nach Empfang eines gestorten Telegramms, 
wobei fur den aufgetretenen Stdrungstyp eine 
Telegrammwiederholung vorgesehen ist, wird 
der zweite Zahler (CIVSTA) inkrementiert, 
der Empfanger deaktiviert und eine Verzoge- 
rungszeit (delay) gestartet; nach Ablauf der 
Verzogerungszeit (delay) wird ein Wiederho- 
lungs-Anforderungstelegramm (UREL, IREL) 
mit Kennung (varec, civtel) gesendet und da- 
nach der Empfanger wieder aktiviert; 
n) wird in einem Pakel ein Datentelegramm- 
Anforderungstelegramm (UREN, IREN) emp- 
fangen, konnen wieder Datentelegramme 
(UD, ID) aus dem Datensendepuffer gesendet 
werden, ohne auf das Ende des Empfangs des 
kompletten Pakets zu warten; 
o) wird in einem Paket ein Datentelegramm 
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(UD, ID) empfan^^wird erst auf das Ende 
des Pakets gewartet, um einen kompletten Da- 
tensatz zu empfangen und um diesen durch 
Eintragen in den Datenempfangspuffer kom- 
plett an die datenverarbeitende Einrichtung 
der Station (U, I) weiterzugeben. 
12. Verfahren nach Anspruch 11, dadurch gekenn- 
zeichnet, daB als gesonderte Regeln zur Veranlas- 
sung einer Telegrammwiederholung (vergl. An- 
spruch 11, k) nachstehende Regeln definiert sind, 
gemaB denen nach Empfang eines Wiederholungs- 
Anforderungstelegramms (UREL. IREL) mit einer 
Kennung (CIVTEL) eine Telegrammwiederholung 
gemaB den Backup-Regeln veranlaBt wird und 

a) wenn der zweite Zahler (CIVSTA) gleich 
der Kennung (CIVTEL) ist und falls der zweite 
Zahler (CIVSTA) nicht Null ist. wird der zwei- 
te Zahler (CIVSTA) vor der Telegrammwie- 
derholung inkrementiert und nach der Tele- 
grammwiederholung ein Anforderungstele- 
gramm (UREL. IREL) gesendet; 

b) wenn der zweite Zahler (CIVSTA) groBer 
ist als die Kennung (CIVTEL) wird nach der 
Telegrammwiederholung ein Anforderungste- 
legramm (UREL. IREL) gesendet; 

c) wenn der zweite Zahler (CIVSTA) kleiner ist 
als die Kennung (CIVTEL). wird vor der Tele- 
grammwiederholung der zweite Zahler (CIV- 
STA) geloscht und falls der Merker (WRR) 
gleich 1 ist, wird nach der Telegrammwieder- 
holung ein Anforderungstelegramm (UREL, 
IREL) gesendet 
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